1. OpenID Foundation Avatar OpenID Foundation
  2. WGs
  3. connect
  4. Issues

Requesting Verifiable Presentation

Issue #1238 resolved
David W Chadwick created an issue

Relying parties can have quite complex needs in terms of the VCs/claims they require to be inserted in a VP. The current document only has a simplistic way of requesting claims. For example, it does not allow for disjunctive claim requests but only conjunctive ones. Furthermore if the RP’s requirements are sent privately in the OIDC protocol between the RP and OP, so there is no guarantee that this request will conform to privacy legislation such as GDPR. For these reasons I would like to request the option of sending a pointer to a public policy server where RPs can store their policies. This has a number of advantages such as:

i) the same policy can be referred to by multiple RPs e.g. a policy for entering all the nightclubs in a region or country

ii) the ICO can inspect RPs published policies to see that they are compliant with legal requirements

iii) this stops unscrupulous RPs sending a privacy revealing policy to an OP but notifying the ICO of a different more privacy protecting one.

iv) it allows more complex policies to be specified according to need e.g. the policy store could hold a DIF PE policy or another policy format defined by a federation of users.

This feature can be enabled by introducing a new property “credential_policy” as an alternative to “credential_types” where “credential_policy” is defined as

"credential_policy": {
"policyURL": "<url of public policy server>",
"policyMatch": {
"any": "definedPolicyMatchingObject"
}
}

The policy match could be a simple “type” with any string value, e.g. “type”:”my resource policy” or it could be an “action” on a “resource” e.g. {“action”:”enter”, “resource”:”nightclub”}.

Comments (26)

  1. Torsten Lodderstedt

    Having the option to refer to an externally hosted credential request seems an interesting option wrt auditing and so on.

    However, I would never use this exclusively simply because it’s to static and unnecessary limit the RP’s ability to request the credentials/claims required in a certain transaction.

    Additionally, there are other solutions to cope with large requests. Namely PAR is increasingly used for that purpose (and part of FAPI2).

  2. David Waite

    I suspect the ideal model is that the credential is defined at issuance time and requests for that credential need to work within that definition.

    Otherwise, the software the holder is using will not understand how to perform activities like informed user consent - and you cannot really trust the verifier to send dynamic, displayed content for display to the user without such a system being abused.

  3. Kristina Yasuda

    I think such policy can be part of the Verifiable Presentation itself - in termsOfUse property for example?

  5. David W Chadwick reporter

    Torsten “However, I would never use this exclusively simply because it’s to static and unnecessary limit the RP’s ability to request the credentials/claims required in a certain transaction.”

    This is not how we use it. We implement least privileges by having different policies for each resource so that as the user moves around an RP’s different resources different policies can be activated. With traditional SAML and OIDC login the user gets maximal privleges as all the attributes are sent on login. With policies per resource the user gets least privileges.

  6. David W Chadwick reporter

    Kristina “I think such policy can be part of the Verifiable Presentation itself - in termsOfUse property for example?”

    Not so, because we are talking about the request to the user from the RP, not the response (the VP is the response which contains the VCs that match the policy)

    ‌

  7. David W Chadwick reporter

    Kristina. re presentation exchange. This can be stores as a policy in the policy server and the request can point to it.

  9. Nat Sakimura

    Just FYI.

    OpenID Connect’s request_uri facility actually was partly designed for this purpose so that the “trust framework operator” or “privacy protection agent” can check for collection minimization adherence etc.

  10. David W Chadwick reporter

    Thanks Nat. I think this provides what I was looking for wrt to the RP telling the OP where to find its claims requirement policy. If you agree that request_uri can be used for this, then we can mark this issue as resolved by saying, use the request_uri to encode the policyURL and policyMatch parameters.

  11. David W Chadwick reporter

    p.s. the DIF presentation request could be transferred this way as well, and that will also resolve issue #1230

  13. David W Chadwick reporter

    Can I request that the openid-connect draft contains an example in Section 9 for the use of the request_uri parameter to point to where the verifiable presentation claims requirement policy can be obtained. Thanks

  14. David W Chadwick reporter

    As I read Section 8.1 it does not seem to be possible to use the request_uri parameter to specify which types of claim are required, since the text mandates credential_types to be present, viz:

    credential_types Object array containing definitions of credential types the RP wants to obtain

    type REQUIRED String denoting a credential type

  16. David W Chadwick reporter

    In addition the OIDC standard definition for request_uri, as I read it, does not fulfil exactly what is needed, because it requires the claims to be specified in OIDC format rather than in some externally defined policy format viz:

    request_uri OPTIONAL. This parameter enables OpenID Connect requests to be passed by reference, rather than by value. The request_uri value is a URL using the https scheme referencing a resource containing a Request Object value, which is a JWT containing the request parameters.

    What is actually needed is a reference to a publicly accessible policy store, where the policy can be retrieved by anyone (including the ICO to ensure conformance to GDPR). So the request_uri should contain the https location of the policy server, plus a match parameter/search string which enables the policy server to locate the referenced policy and return it to the OP.

  17. David W Chadwick reporter

    The current OIDC claims mechanism is too simplistic for a large number of VC use cases, in which a number of alternative VCs are required, with selective disclosure rules for each one. As I read it, the existing OIDC claims mechanism does not support disjunctive requests, nor selective disclosure of attributes from a credential. Also, if VCs really take off, the types of VCs will explode (consider the different types of plastic cards that are available today, there are hundreds if not thousands of them). So an extensibility mechanism for claim types will need to be supported, which VCs do.

  18. Torsten Lodderstedt

    If you want to specify a policy in some non OIDC format, I think you are looking for a different extension. OIDC4VP (in the same way as OIDC4IDA) extend the existing OIDC syntax to extend the functionality for OIDC RPs.

    The extension you might be looking for would need to specify how non OIDC formats need to be transformed into something an OIDC OP can process.

    Can you please give a concrete example?

    re your original requirements in this ticket:

    • complex requirements (such as this credential type or another one or some combinations) do require a more sophisticated request language. The idea is to adopt PE elements (optionally) for that purpose.
    • If you want to implement legal compliance by restricting the dynamic of OIDC authentication requests, the OP must also enforce static requests only for the respective RPs. This , in my opinion, should be described in a separate spec along with architecture and trust thoughts, as it is applicable to all kinds of OIDC deployments (not only those using VPs).

    ‌

  19. David W Chadwick reporter

    The model I am using is for a SIOP in (or next to) the user’s VC wallet. The RP sends its policy reference to SIOP and SIOP passes it to the wallet. Existing VC wallets already process policies from RPs and produce a VP to satisfy the policy. But they all use different protocols. I would like them to converge on OIDC SIOP. So today there is no problem in VC Wallets handling policies in different (non OIDC) syntaxes. The SIOP hands the policy reference to the existing wallet in the smart phone, and it knows how to process the policy in whatever syntax it is in. The DIF PE work is attempting to standardise this policy format, but until that is widely accepted we will have different policy formats. However, that is not an issue, since the public policy server can hold the same semantic policy in different syntaxes allowing the wallet to pick up the syntax it supports. I am giving a presentation about this to the Linux/CCI group this Tuesday if you are interested.

  20. David W Chadwick reporter

    To answer Torsten’s specific questions and points.

    1. The extension you might be looking for would need to specify how non OIDC formats need to be transformed into something an OIDC OP can process. Ans. The SIOP wont process the policy, but the VC Wallet will.
    2. Can you give a concrete example. Ans. I have a video on Youtube showing the purchase of a car parking permit online by presenting three VCs with selective disclosure from each and combining them into a VP to return to the RP. But of course if currently uses HTTPS and not OIDC protocols. You can watch it here https://youtu.be/w0FJayxCYwk
    3. The idea is to adopt PE elements (optionally) for that purpose. Ans. That is not represented in the current protocol draft, hence this issue. But if we agree to represent the semantic content of PE as OIDC claims that could work. But it does not answer the compliance issue.
    4. f you want to implement legal compliance by restricting the dynamic of OIDC authentication requests…Ans. There is no intention to reduce the dynamicity. On the contrary, the mechanism I am proposing is just as dynamic as what you have today but also supports least privileges since different policies can be returned to each resource access request. We demonstrated this several years ago to the NHS, and describe this in our paper David W Chadwick, Romain Laborde, Arnaud Oglaza, Remi Venant, Samer Wazan, Manreet Nijjar “Improved Identity Management with Verifiable Credentials and FIDO”. IEEE Communications Standards Magazine. Vol 3, Issue 4, Dec 2019, Pages 14-20. You can download this for free from https://kar.kent.ac.uk/80304/

    ‌

  22. Jeremie Miller Account Deactivated

    During the SIOP discussion today Justin described the use of request_uri in the OpenID Connect spec section 6.2.

    While there are known security challenges using this pattern for a traditional authorization requests where the URI could point anywhere, in the use case described in this issue the URIs would all be well-known trusted endpoints from a policy server or as part of a trust framework.

    The by-reference request pattern also already supports the ability for the client to include values such as the nonce per-request, only the trusted fixed values are sourced at the URI.

    I believe this is readily usable for policy/framework use cases with SIOP and presentations where there is a larger agreement in place on the authority of the hosted request objects.

  24. Kristina Yasuda

    This issue seems to be duplicative with Issue #1340 and we are reaching the same conclusion in both issues ,so could we merge the two issues into this one and rename this one to “Sending the presentation definition by reference“?

  27. Log in to comment
Assignee
Type
enhancement
Priority
major
Status
resolved
Component
Verifiable Presentation
Milestone
–
Version
–
Votes
0
Watchers
7
Jira: the preferred issue tracker for Bitbucket. Join the team!